-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes #38015 - Enable org and CVE scoping for flatpak content #11251
base: master
Are you sure you want to change the base?
Conversation
eb3bc3d
to
6bb32d1
Compare
6f1e993
to
8373f5a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is working fine for me as-is. A question about the comment:
@@ -806,5 +806,25 @@ def render_podman_error(code, message, status = :bad_request) | |||
def item_not_found(item) | |||
render_podman_error("NAME_UNKNOWN", _("%s was not found!") % item, :not_found) | |||
end | |||
|
|||
def static_index | |||
host_ip = request.remote_ip |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why identify based on IP rather than hostname? Will this have implications for IPv6? In registration_manager we look at the hostname; there may be stuff you could reuse in there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh I just remembered that in registration_manager it's the hostname of the capsule, not of the host. So possibly nevermind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me see if I can grab hostname here..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see something like this from resolv could work. We do something similar in foreman in atleast a text search I did on the repo.
Resolv.getname(request.remote_ip)
remote_ip should be able to provide ipv4 or ipv6 address whatever is passed to the request header by the client. As long as we store that on the host's nic ip, we should be able to get the host record.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should be able to resolve ipv4 or ipv6 address I believe via the same getname
method.
I think one big question is if we should rely on Foreman's primary interface or DNS to resolve the IP to a hostname. Can we always rely on DNS being available? Foreman relies on DNS a lot so I think that might be true, but it might be worth asking someone from the platform side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adamruzicka : Would you know if this is a good way to get the host from request.remote_ip and would this be ipv4/v6 proof?
Host.joins(:primary_interface).where("nics.ip = :host_ip OR nics.ip6 = :host_ip", host_ip: host_ip)&.first
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we always rely on DNS being available? Foreman relies on DNS a lot so I think that might be true
I would suggest against relying on this. Foreman may not be able to resolve hostnames that are managed by a dns server running in a remote location, even if that remote location's dns server is managed by a smart proxy. I'm also not sure if we also set up PTR records or just A/AAAA ones.
if we should rely on Foreman's primary interface
Why limit ourselves only to the primary interface?
Would you know if this is a good way to get the host from request.remote_ip and would this be ipv4/v6 proof?
From the top of my head I can't think of any other approach and it should be ip-version agnostic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Adam!
Why limit ourselves only to the primary interface?
I found other instances of using primary interface to get/set host's ip address in foreman..Is there some other interface we can use for our purpose here?
From the top of my head I can't think of any other approach and it should be ip-version agnostic.
Updated to use the above query to look at ipv4 and ipv6..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about collecting the IPs from all host interfaces? Host.first.interfaces
...
We'd be even more likely to get a hit in case a different NIC is used for flatpak.
8373f5a
to
15de19c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm cool with how this is now, if we get more information about a better set of interfaces to query we can make adjustments later.
What are the changes introduced in this pull request?
Considerations taken when implementing this change?
What are the testing steps for this pull request?
Sync a few flatpak repos in different orgs and add them to some content view.
Create activation keys for those CVEs and then register a host using the key.
Setup a host to consume flatpak content from the katello server. Use server/index/static url instead of server/pulpcore_registry/ endpoint..
Try flatpak remote-ls and ensure you only see repos the host has access to.